Request Lifecycle
Introduction#
SpiralはすでにWebページを生成する機能は備わっています。 ただ、こんな風に困ったことはありませんか？
- カスタムページを都度生成して遷移のURLを書くのが大変
- 共通のヘッダーやフッターを作って反映する方法を考えるのが面倒
- どこに何のソースが使われているか不明瞭で改修するのが怖い
こういった問題はこのフレームワークを使うことで解消します。 基本的にはこのフレームワークは1つのURL（カスタムページ）を利用して独自のルーティングを行います。
これにより、URLのパラメータによって取得すべきファイルを分けることができ、SPIRAL上での操作も不要になります。
ただ、このフレームワークは認証認可機能は備わっていません。そこはマイエリアの機能に頼りましょう！
ライフサイクルの概要#
最初のステップ#
すべてのリクエストエントリポイントは、Startup/web.php もしくは、Startup/hoge.php です。 このファイルにルーティングの設定を書き、それを読み込むことでソースコードを取得し処理を行います。
また、デプロイコマンドを利用することで、あたかもcomposerによるautoload.phpがあるかのようなふるまいが行えます。 独自のトポロジカルソートにより実現されています。
HTTPカーネル#
次に取得した要求はアプリケーションに入る要求のタイプに応じてHTTPカーネルに送信されます。 このカーネルはすべての要求が通過する中心的な場所として機能します。
HTTPカーネルは要求から実行すべき順番で処理をさばいていきます。
ルーティングの設定で記述したミドルウェアの要求が問題なく通過するか、CSRFのセキュリティ要件に沿った要求かをフィルタリングし、もしエラーとなった場合に不要な処理が通過しないようにコントロールされます。
サービスプロバイダー#
サービスプロバイダーは通常、データベース、キュー、検証、ルーティングコンポーネントなどをブートストラップする役割を担いますが、 SPIRALの制約のもとこれを実現することはできませんでした。 ただし、依存性の逆転にそってDIコンテナのような役割を別途用意しています。 ルーティングの説明にて詳細に伝えます。
ルーティング#
routes/web.php もしくは、routes/hoge.php にてルーティングの設定が行われます。 通常、URLのパラメータとマッチしたルーティング情報が呼び出され、処理が実行されます。 例えば、
https://hogehoge/fuga?_path=/usersこのようなアクセスに対応したルーティングはこのように作ることができます。
Router::map("GET", "/users", function(){ echo "Users!!";});詳細については、The Basics / Routingをご覧ください。